The rapid evolution of technology has posed significant problems, as well as benefits. Some technologies never achieve their full potential while others evolve rapidly, leaving earlier versions obsolete shortly after they have been installed. Technologies typically need to be substituted or otherwise adapted to compensate for different needs, requiring wholesale redesigns even when the redesign employed similar building blocks. It is well-known that software can be used to allow integration of new hardware or allowing existing hardware to fulfill new functions without starting from scratch.
Large-scale software development has evolved rapidly from its inception. Through the 1980s large-scale software was developed in modular systems of subsystems, and even today these are the most common systems in use. These systems are largely hardware dependent, and problems or errors can be detected down to the level of the subsystem. These systems were based on point solutions where the problem/solution is functionally decomposed into subsystems. Unfortunately, potential reuse of the software for other applications must have been anticipated during development and integrated into the software design. Extensions of the software are difficult and can only be achieved when such extensions were anticipated and designed into the system architecture itself.
In the 1990s, some improvement came with the advent of Object Oriented Systems (OOS). OOS are still hardware dependent topologies, as they are designed for specific hardware configurations and modules are not produced. These systems were based, like their predecessors, on point solutions and are deficient in a number of respects. The point solutions for OOS are derived using Object Oriented Analysis. Extension of the system using existing components was difficult as a result of the multiplicity of languages used.
A prior art interoperable architecture is SCA—Software communication architecture. This architecture is used in such applications as SDR (Software Defined Radio). SCA has specific IDL (Interface Definition Language) interfaces defined for software radios. Any new desired capabilities must fit in to pre defined IDL. SCA provides an interface framework; as such, it is not hardware independent. While peer- upper layer interfaces are well defined in SCA, lower layer interfaces are largely ignored. Another disadvantage of SCA for more general application is its total reliance on CORBA layered communications. Such problems present themselves in CPU overhead and quality of service. Messages can be delivered out of order and processed by different threads when belonging to the same data streams. However, once again, the theoretical benefits have yet to be realized due to a number of underlying factors. In addition, the SCA design does not address the FPGA concerns detailed herein.
In recent years, research has centered on layered or component based systems. In theory, such a system has a thin common layer or component base class that is used in the development of all software modules. Each of the major capabilities of the system is represented by at least one module or component. These modules or components are thus “wrapped” in the thin common layer. Independent components are developed, tested, and packaged independently of each other, and while operating have no knowledge of their environment, since all input/output is constrained to interface ports connected from the outside. Run time discoverable parameter ports control specific behavior. Software components would allow reuse by performing a particular function and providing an appropriate interface with a larger system. Each component would ideally be autonomous regarding its particular functionality. This autonomy would allow changes to be made with individual components without disturbing the configuration of the entire system. Relating the various quasi-autonomous components to each other results in a high degree of complexity in communication and synchronization code.
A system of reusable and flexible components is especially useful for military contractors. In the past, software was designed specifically for a single contract. When a new contract was bid, the contractor stated from scratch. As discussed herein, differences in language and architecture prevented different functionalities from being reused from earlier contracts. Since the software was newly developed there remained a relatively high risk of failure in the software or its interfaces, therefore the new software required testing and debugging, adding to the cost of the contract. The application of a flexible framework of reusable and interchangeable components would enable a designer to leverage earlier development investments and minimize risk of failure in the development process. Contractors would be able to provide clients with more accurate and lower bids and possibly prototypes or catalogues of products easily configured to the clients needs.
The use of object oriented, distributed framework based software systems has led to improvement in the modularization of software, but has increased the complexity of the hardware. The heterogeneity of the distributed computing platform means that the interfaces with field programmable gate arrays (FPGA) and similar devices became increasingly complex. Interfaces between processors eat into valuable computing time and retard calculations. In applications that require real time processing, the general purpose processors are not satisfactory. In addition, the power requirements also become excessive.
In order to achieve real time processing, field programmable gate arrays (FPGAs) are employed. The applications coded in hardware design language (HDL) running on FPGAs achieve orders of magnitude speed improvements over their software counterparts running on general purpose computers. The reconfigurability of the FPGAs provides adaptive processing, and high density FPGAs currently accommodate multiple complex applications running in parallel. But, there are significant problems in integrating multiple applications, which run on FPGAs and boards manufactured by the various manufacturers, into a coherent form.
Distributed processing systems of general purpose or special purpose computers, use a framework of common electrical, physical, and logical interfaces to specify and enforce compatible interfaces between software programs that perform discretely defined processing (components). In a distributed processing system of general purpose or special purpose computers, signal and specialized data processing can consume more processing time and resources than can be provided in a processor. To obtain more processing per volume or per cost the prior art uses specialized digital hardware such as FPGA's, or special purpose integrated circuits. These mechanisms do not provide a common, controllable interface that can interface in a common way to other software-based signal and data processing components in the distributed system. Customarily, large computations of partitionable problems with time constraints are performed using distributed processing.
There is a significant desire for faster and denser FPGA's, particularly in fields such as signal intelligence (SIGINT) that perform front end processing of data from various sensors. The faster the computational algorithms and digital signal processing functions are processed the faster the system can respond. Unfortunately, the core functions are designed and implemented for each specific task without any consideration of code reuse or interoperability between cores or both which results in expensive modification costs when a different FPGA is targeted.
These specialized interfaces may have commonality in terms of physical and electrical interface, but have not been common in terms of logical interface, nor have had the complexity required of modem software based interfaces. These prior mechanisms do not provide a common, controllable interface that can interface in a common way to other software-based signal and data processing components in the distributed system.
The evident reduction in engineering effort and minimization of difficulties associated with the specification, harmonization and enforcement of compatible interface between software programs executing in a network of general-purpose computers suggested the possibility that a similar approach might be taken with computing nodes containing FPGAs, gate arrays, and or special purpose integrated circuits.
A description of the difficulties in the prior art implementation of FPGA boards is described in “From Algorithm to Hardware—The Great Tools Disconnect”, from the COTS Journal, October 2001, pages 48–54. A further discussion of alternative designs tried under DARPA is discussed in “VSIPL: Developing Portable Applications for COTS” COTS Journal, October 2001, pages 57–63. In addition, there is a Common Component Architecture (CCA) Forum established by researchers from national labs and academia that are seeking to establish a standard component architecture for high performance computing. The CCA Forum internet site at http://www.cca-forum.org and there are numerous papers, articles and presentation material of general interest.
There are certain board vendors that provide circuit boards with FPGA's, such as those by Annapolis Microsystems, but the implementation has an internal interface scheme that does not provide for a standard interface for other commercial off the shelf (COTS) items.
In summary, while such an approach for interoperability and code reuse is desirable, the implementation has not been successful. Prior efforts have not been successful to structure a framework that allows the apparent benefits of such a system. The integration of hardware design language (HDL) core functions to run on commercial off the shelf (COTS) platforms involving multiple vendors has several pitfalls. For example, the core functions are not written in the same HDL language and may have been coded in VHDL, AHDL or Verilog. The core functions are generally uniquely written for a given FPGA family which makes them chip dependents. The core functions are also generally written for a given COTS or proprietary board, making them board dependent. Finally, the core functions do not have a well-defined interface to facilitate concatenating cores together to design more complex functions.
Clearly what is needed is an interface layer to a core application in order to have reusable HDL cores that are independent of the hardware. There should be some manner in which the cores from various vendors can be mated with a system to allow a ‘plug and play’ environment and thereby reduce cost and time to market.